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Summary of the prosecution 

20 On 12/30/02, Examiner mailed a first Office action in the above application in which he 
required a new Declaration, required correction of the Drawing as specified in the Notice 
of Draftperson's patent drawling review, PTO-948, objected to the Drawing as having two 
identical figures, and required correction of the drawing; objected to the Specification; 
and objected to various informalities in claims 11, 12, 13, 14, 26, 27, 28, and 43. 

25 Examiner further rejected claims 2-23, 39-62, 64-94, and 96-125 for indefiniteness under 
35 U.S.C. 112, second paragraph, rejected claims 1, 24, 28, 29, 31, 34, 35-37, 38, 63, 
and 95 under 35 U.S.C. 103(a) as obvious over Lowery, Managing projects with 
Microsoft Project 4.0 for Windows and Macintosh, version 4.0, Van Nostrand Reinhold, 
1994 (henceforth "Lowery"), rejected claims 25, 33, and 36 under 35 U.S.C. 103(a) as 

30 being unpatentable over Lowery combined with ManagePro 2.0 for Windows, version 
2.0, Reference Manual, Avantos Performance Systems, Inc., 1993 (henceforth 
"Managepro"), and rejected claims 26, 27, 30, and 32 under 35 U.S.C. 103(a) as obvious 
over Lowery in combination with published U.S. patent application 2001/0027455, 
Abulleil et al., having an effective filing date of 8/21/98 (henceforth "Abulleil"), 

35 Applicant amended his Specification, Drawing, and claims to overcome the objections 
thereto and traversed the rejections of the claims under 35 U.S.C. 1 12, second paragraph 
and 35 U.S.C. 103(a) in a response filed on 4/28/03 with a one-month extension of time. 
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Applicant received a second non-final Office action in the above application mailed 
7/16/03. In the second Office action. Examiner indicated that Applicant's traversal of the 
rejections had been persuasive. Examiner objected to the Specification and Drawing on 
5 the basis of further errors and objected to claims 14, 19, 85, 86, and 122 because of 
informalities. In his new grounds of rejection, Examiner rejected claims independent 
claims 1, 38, 63, and 95 as lacking patentable utility and as being addressed to non- 
patentable subject matter. The dependent claims were rejected as being dependent on 
claims 1, 38, 63, and 95. 

10 

Examiner further rejected claims under 35 U.S.C. 103 as follows: 

• Claims 1-26, 28, 29, 31, 34-62, and 95-125 as being unpatentable over Lowery in 
view of Pearce, et al., Strategic Management: Formulation, Implementation, and 
Control, 4th edition, Richard D. Irwin, Inc., 1991, henceforth "Pearce". 

15 • Claim 30 as being unpatentable over Lowery in view of N. Tatum, Verity and Yahoo! 
Inc, Sign Distribution Agreement, Verity, Inc., Surmyvale, CA, April 12, 1999, 
henceforth "Tatum". 

• Claims 32 and 33 as being unpatentable over Lowery in view of Managepro 2.0 
Reference Manual (Managepro 2.0 for Windows, version 2.0, Reference Manual, 

20 Avantos Performance Systems, Incorporated, 1993), henceforth "Managepro" 

• Claims 63-94 are rejected as being unpatentable over Lowery in view of Pearce and 
Carter, "As program management Function evolves, Benefits Increase", Water 
Engineering and Management, Des Plaines, Vol. 142, issue 3, Mar. 1995. 

Applicant rendered the foregoing rejections moot by replacing the claims then in the 
25 application in the application with a new set of claims 126-186. In replacing the present 
claims. Applicant was by no means conceding the correctness of Examiner's rejections of 
the present claims, but rather merely taking advantage of his right to claims which set 
forth his invention in the most advantageous maimer. 

30 Applicant next received a restriction requirement in the application in which Examiner 
determined that the original claims were classified in class 705, subclass 7, while the new 
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claims 126-186 were classified in class 709, subclass 204. Examiner further determined 
that since Applicant had already received an action on the original claims, Applicant had 
constructively elected the invention of the original claims for prosecution on the merits. 
On the basis of that determination, Examiner withdrew new claims 126-186 from 
5 consideration as being directed to a non-elected invention. 

Applicant responded to the restriction requirement by canceling claims 126-186 without 
prejudice and adding new claims 187-210 which overcame the restriction requirement 
and demonstrating why the new claims are patentable over the references. Examiner 

10 thereupon mailed a final Office action on 5/27/04 in which he rejected all of the 
remaining claims 187-210 on the basis of new references. Claims 187, 188, 189-193 
were rejected under 35 U.S.C. 102(b) as being anticipated by U.S. patent 5,655,118, 
Heindel, et al., Methods and apparatus for managing information on activities of an 
enterprise, issued 8/5/97 (henceforth "Heindel"), claims 195-196 were rejected under 35 

15 U.S.C. 103(a) as being obvious over the combination of Heindel with US. Patent 
5,530,861, Diamant, et al., Process enaction and tool integration via a task oriented 
paradigm, issued 6/25/96, and claim 196 was rejected under 35 U.S.C. 103(a) as being 
obvious over the combination of Heindel with official notice. Claims 197-210 are 
addressed to substantially the same subject matter as claims 187-196 and are rejected for 

20 the same reasons. Applicants are filing an RCE with a submission under 37 C.F.R. 1.114 
which traverses the rejections. 

Traversal 

The problem attacked by Heindel, Applicant, and many other so-called project 
25 management systems 

The problem that motivates people to build interactive project management systems is the 
difficulty of understanding what is going on in an organization. The systems work by 
providing a model of the organization which users of the system may view and 
30 manipulate. The model is generally implemented using a relational database. One 
approach, used in systems such as the one described in the Lowery reference, is to 
provide a single model into which all kinds of organizations must be made to fit. 
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Organizations are typically hierarchically organized, and in Lowery, the model is a 
simple hierarchy. If an aspect of an organization does not fit the hierarchical model, it 
cannot be expressed in the system of Lowery. See in this regard the discussion at col. 2, 
line 30-coI. 3, line 3 of Heindel. 

5 

Heindel solves the problem of aspects of an organization that do not fit the hierarchical 

model by permitting the user to make any kind of model he or she wants of the 

organization. As shown in Heindel' s FIG. 2, a model made using HeindePs system may 

be made up of strategic plans, projects, tasks, products, subprojects, or employees, and 

10 any of these elements may be related to any other of these elements. As set forth at col. 

6, lines 62-65 of Heindel, 

activity information data elements are stored in the database 200 using a 
non-hierarchical entity relationship model, as opposed to the hierarchical 
models employed by conventional project management systems. 

15 

FIG. 5 gives an example of the kinds of models that can be made using the system of 
Heindel, 

Heindel's system overcomes the limitations of the simple hierarchies of Lowery, but it 
20 does so at a cost: 

• Because the user can make any kind of model, it is left to the user to decide in every 
respect how the organization should be modeled. In effect, every user who employs 
Heindel to model an organization must "reinvent the wheel". 

• Because the models made using Heindel's system may be completely arbitrary, they 
25 will be difficult for users other than the creator of the model to understand. 

• The generality of the system requires a high degree of complexity in the database 
itself and in the user interface and report generation systems. 

The problem posed to the user by systems like the Lowery system on the one hand and 
Heindel's system on the other is this: Lowery 's simple hierarchical model is easy to 
30 understand and use, but is not powerftil enough to model many commonly-occurring 
aspects of organizations. For example, it cannot easily deal with cross-hierarchical 
organizational functions such as HR or accounting or cross-hierarchical matters such as 
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customer satisfaction. Heindel, on the other hand, can model anything, but each 
modeling problem must be approached from scratch and neither model makers nor model 
users cannot use experience gained with one model made using Heindel's system to 
understand another model made using Heindel's system. 

5 

Applicant's "system for supporting management of a business by people involved 
therein" solves the problem posed by the limitations of Lowery and the complete 
generality of Heindel by providing a model which permits an organization to be viewed 
from two hierarchical perspectives. The first of these perspectives is a hierarchy of goals, 

10 which is similar to the hierarchy provided by a planning tool such as Lowery. The 
second of these is a hierarchy of domains, that is, elements of the business model which 
cut across the hierarchy of goals. An element of the goal hierarchy may also belong to a 
domain in the hierarchy of domains. FIG. 8 shows a typical domain hierarchy; as can be 
seen from the figure, the domains are business concerns which cut across many goals. 

15 The goal hierarchy is described at least at page 22, line 19-page 23, line 7 of Applicant's 
Specification and shown in FIGs. 13-15. FIG. 16, finally shows how the goals in the goal 
hierarchy may be sorted by the domain hierarchy, so that a user of the system can see the 
goals in the context of the domain hierarchy. 

20 By adding the domain hierarchy to the goal hierarchy and permitting elements of the goal 
hierarchy to be related to elements of the domain hierarchy, Applicant's management 
support system permits models which provide perspectives lacking in the simple 
hierarchies provided by Lowery while avoiding the complexities of Heindel's generalized 
modeling system. Both the goal hierarchy and the domain hierarchy are intuitive in 

25 themselves, and the manner in which an element of a domain hierarchy may also relate to 
a domain in the domain hierarchy is also easy to understand. Further, since all models 
made using Applicant's modeling system have the same characteristics, model makers do 
not have to constantly "reinvent the wheel" and users who encounter new models made 
using Applicant's modeling system already have the knowledge needed to the models' 

30 basic structures. 
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Patentability of Applicant 's claims over Heindel 

Applicant's independent claim 187 clearly sets forth the characteristics of Applicant's 
modeling system which distinguish it from the simple hierarchical modeling system of 
Lowery and from the completely general modeling system of Heindel: 

5 

187. A system for supporting management of a business by persons 

involved therein, 

the system comprising: 

a processor which has access to a representation of a 

10 model of the business, the model including representations of model 

entities, the representations of model entities belonging to a hierarchy 
and/or another hierarchy, and the representations of model entities 
providing access to information relating to the business and 

an interface to the system for the persons, the interface 

15 being provided by the processor and the interface permitting a person to 

perceive and modify the model entities and the hierarchies and to perceive 
and modify the information to which the model entities provide access. 

The claim sets forth that the model "includes representations of model entities, the 
20 representations of model entities belong to a hierarchy and/or another hierarchy" and that 
an interface to the system "permit[s] a person to perceive and modify the model entities 
and the hierarchies". As Examiner properly understands, the limitation that a 
representation of a model entity may belong to a hierarchy and/or another hierarchy of 
course immediately distinguishes Applicant's models from those of Lowery. The 
25 limitation that the representation belongs to a hierarchy similarly distinguishes 
Applicant's models from those of Heindel, which has no such requirement. 

It should be pointed out here that the generality of Heindel' s modeling system permits it 
to be used to make any kind of model for an organization, including a simple hierarchical 

30 model like those of Lowery and models of the kind set forth in Applicant's claim 187. 
That fact does not, however, mean that Heindel anticipates claim 187. What Applicants 
are claiming is a model with the specific properties set forth in claim 1 87, and the issue is 
whether there is anything in Heindel which discloses or suggests that a model made with 
Heindel's system should have the specific properties set forth in claim 187. With regard 

35 to that issue, the answer is clear — a model organized in the fashion of the model shown in 
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Heindel's FIG. 5 cannot reasonably be considered to be hierarchical, and Heindel further 

expressly teaches away from the use of hierarchical models in the business context. See 

for example col. 6, lines 3 1-36: 

It is important to note that the activity information data elements 400 do 
not rely on hierarchical constructs where strategic plan (SP) elements 
relate to one or more product (PR) elements that relate to one or more 
project (P) elements that relate to one or more subproject (S) elements that 
relate to one or more task (T) elements that relate to one or more employee 
(E) elements. 

There is thus nothing whatever in Heindel which discloses or implies what Applicants are 
claiming or that a system that employs models like those set forth in claim 1 87 could 
overcome most of the limitations of simple hierarchical systems like Lowery without the 
complexity of Heindel's system or of models like those shown in HeindePs FIG. 5. 



Since that is the case, Heindel cannot serve as the basis for rejecting independent claim 
187, or as Examiner well understands, independent claim 198. Because that is the case, 
claims 187-210 are all patentable over the reference. As regards the dependent claims, 
claims 188 and 199-200 are further patentable in their own rights because Heindel's 

20 failure to disclose the hierarchies of Applicant's model also means that it caimot disclose 
sorting or displaying model elements according to those hierarchies. There is further no 
specific disclosure at all in Heindel of any kind of user interface to his modeling system, 
so there is nothing corresponding to the limitations of claims 191-196 and 203-206. 
There is also nothing in Heindel that indicates that an entity in the model representation 

25 can be used to access additional related information, as set forth in claims 192-197 or 
claims 207-209. These claims are thus also patentable in their own rights over Heindel. 

Examiner further rejects claims 194-196 under 37 C.F.R. 103. These rejections require 
of course that Heindel disclose all of the limitations of claim 187 and as already set forth, 
30 Heindel does not do that, and consequently, Heindel in combination with the other 
references cannot provide a basis for the rejection. In addition, Diamant does not 
disclose the "messages" and "discussions" of claims 195 and 196. The problem here is 
that the messages of Diamant are clearly messages sent by system components to other 
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